Cinq défis que l'IA n'a fait que rendre visibles
Combien d'heures de votre projet d'automatisation des tests sont consacrées à la maintenance plutôt qu'à l'ajout de nouvelles fonctionnalités ? Et quelle part du savoir-faire qui assure la cohérence de votre projet repose sur seulement deux ou trois personnes ?
Nous nous sommes posé les questions suivantes dans le cadre d'un projet client dans le secteur des assurances : plusieurs centaines de transactions commerciales automatisées pour de nombreux clients, testées de l'interface utilisateur à la base de données, dans un environnement réglementé où chaque test influence la validation de la mise en production. Lors de la mise en œuvre de Claude Code, cinq problèmes qui nous freinaient depuis longtemps, mais que personne n'avait abordés ouvertement auparavant, ont été mis en lumière.
Situation initiale
Nous sommes responsables de l'automatisation complète des tests de cette plateforme de gestion des stocks : des suites de tests qui vérifient l'ensemble de la chaîne, de l'interface utilisateur à la base de données en passant par la logique métier et les interfaces. Les résultats doivent être documentés de manière à garantir leur conformité aux exigences d'audit.
Un projet comme celui-ci prend de l'ampleur. Et avec lui surgit des problèmes dont on parle rarement, car ils surviennent insidieusement. Ce sont précisément ces problèmes qui nous ont fait perdre du temps, et non la rédaction de nouveaux tests.
La première constatation fut donc déconcertante : un assistant IA n’accélère pas automatiquement un projet. Il amplifie ce qui existe déjà – aussi bien l’ordre existant que le chaos ambiant.
Point sensible n° 1 : Dépendance excessive envers certaines personnes
Le problème : dans tout projet de test développé de manière organique, il existe des règles non formalisées. Pourquoi certaines suites de tests ne doivent pas s’exécuter en parallèle. Pourquoi une nouvelle tentative automatique à un point précis est plus nuisible qu’utile. Pourquoi un message d’erreur de la gestion des tests est presque toujours trompeur. Seules deux ou trois personnes dans notre entreprise possédaient ces connaissances.
Chaque équipe en connaît les conséquences. L'intégration des nouveaux collaborateurs est longue. Les erreurs se répètent faute de documentation. Et le projet dépend de la disponibilité de chacun, ce qui représente un risque réel dans le secteur du conseil.
Comment nous avons résolu le problème : Nous avons dû expliquer à l’assistant le fonctionnement du projet. Et pour ce faire, nous avons d’abord dû le définir clairement nous-mêmes. Cette nécessité a conduit à la création d’un ensemble de règles, stockées dans le dépôt, versionnées et accessibles à tous.
Résultat : le plus grand avantage n’a pas été l’assistant, mais la documentation que nous avons rédigée grâce à lui. Ces règles sont désormais la première chose que lisent les nouveaux membres de l’équipe. Elles répondent précisément aux questions que l’on se pose généralement à la troisième semaine, après avoir déjà commis l’erreur.
Deuxième point faible : des tests verts qui ne vérifient rien
Le problème. C'est le sujet le plus délicat de l'automatisation des tests, et il est rarement abordé ouvertement. Un test défaillant s'affiche en rouge et se remarque immédiatement. Un mauvais test s'affiche en vert.
Si un test est appliqué à un ensemble de résultats vide, il s'exécutera. Le test restera dans la suite, consommant du temps d'exécution et créant une confiance injustifiée. Pour les décisions de mise en production, c'est pire que l'absence de test, car personne ne vérifie.
C’est précisément là que réside le véritable risque de l’utilisation de l’IA dans les tests. Un modèle de langage privilégie la plausibilité à l’exactitude. Il fournit une réponse qui semble convaincante, même s’il ignore la réponse correcte. Dans notre cas, il s’agissait de clés métier internes qui ne pouvaient être déduites de l’affichage, malgré les apparences.
Notre solution : nous avons formulé une règle qui n’affecte pas le code, mais le comportement. Une valeur est soit héritée d’un cas de test comparable déjà défini, soit non définie mais marquée comme question ouverte et vérifiée lors de la première exécution. Une valeur qui déclenche un test réussi sans être définie est considérée comme un défaut.
Résultat : l’approche évolue, passant de la simple fourniture d’une réponse à la mise en évidence des réponses manquantes. Un test honnête (indiqué par un rouge) vaut mieux qu’un test trompeur (indiqué par un vert). Ceci est valable indépendamment de l’IA. L’assistant nous a simplement contraints à enfin écrire la réponse.
Point faible n° 3 : Les coûts de maintenance au détriment du développement ultérieur
Le problème : dans de nombreux projets d’automatisation, l’équilibre finit par se rompre. L’équipe consacre plus de temps à maintenir les tests existants qu’à développer une nouvelle couverture de tests. Deux causes principales en sont à l’origine : un accès instable aux éléments d’interface utilisateur, qui deviennent incompatibles à chaque déploiement, et des doublons dus à l’inexistence de composants existants, qui sont donc recompilés.
Les outils d'enregistrement aggravent les deux problèmes. Ils suggèrent de préférence les méthodes d'accès qui fonctionnent au moment de l'enregistrement et qui deviendront rapidement inopérantes par la suite.
Notre solution : nous avons défini une hiérarchie de liaisons précisant quelle méthode d’accès utiliser dans chaque situation, et indiqué explicitement celles qui sont interdites. De plus, nous avons mis en place une vérification : avant la création d’un nouveau composant, une vérification en quatre étapes est effectuée pour déterminer s’il existe déjà.
Résultat : les règles ont un double effet. L’assistant les respecte et l’équipe dispose, pour la première fois, d’une norme écrite pour les revues. Auparavant, la maintenabilité relevait de l’expérience. Désormais, elle est vérifiable.
Point sensible n° 4 : Dépannage qui prend une mauvaise tournure
Problème : un test échoue. Le rapport indique qu’un objet est introuvable. Une recherche de l’objet manquant est donc lancée. En réalité, un jeton d’accès a expiré et l’interface fournit délibérément une réponse trompeuse pour des raisons de sécurité.
De plus, nous avons rencontré un problème que nous nous sommes nous-mêmes créé. Dans les anciennes versions du code, la trace d'erreur technique était supprimée avant même que l'erreur ne soit signalée. Le rapport affichait alors une erreur, mais sans aucune information sur son origine. Chaque analyse devait donc être recommencée à zéro.
Ces deux tâches combinées prennent régulièrement des heures. Et un assistant qui ne possède pas ces connaissances cherchera très efficacement dans la mauvaise direction.
Comment nous avons résolu le problème : La trace de la panne technique est conservée ; c’est une règle stricte de nos jours. De plus, les schémas d’erreur trompeurs connus sont répertoriés dans le manuel, chacun accompagné de l’étape de diagnostic spécifique permettant d’identifier la véritable cause en une minute.
Résultat : les heures récurrentes sont devenues des minutes. Mais le véritable progrès réside dans le fait que ce savoir n'est plus perdu lorsque son détenteur est en vacances.
Point sensible n°5 : Conformité et confidentialité
Le problème : dans un environnement réglementé, la question de ce qui peut être copié dans une fenêtre de discussion n’est pas purement théorique. Une personne enquêtant sur une erreur de connexion pourrait, en cas de doute, copier l’intégralité de la configuration dans un outil, car la rapidité est essentielle. Le risque réside dans le comportement humain. Techniquement, il est impossible de corriger ce comportement.
Notre solution : des directives claires et explicites. Aucune donnée d’accès ni contenu de configuration n’apparaît dans les invites, les journaux, les tickets ou les messages de commit. Aucun contournement des mécanismes de validation du contrôle de version n’est autorisé sans instruction explicite. Aucune modification des composants principaux partagés n’est apportée sans évaluation préalable de son impact sur l’ensemble de la suite de tests.
Résultat : toute personne introduisant une assistance en intelligence artificielle dans un environnement réglementé doit consigner ces points par écrit, et non se contenter d’un accord verbal. Ce sont également les premiers points qui seront abordés lors d’un audit.
La principale découverte
Un assistant IA n'est performant que si le contexte est bien fourni. Et ce contexte ne se crée pas de lui-même.
Les gains de temps significatifs que nous avons constatés sont survenus là où une base de règles claire existait. Cela comprenait la création de nouveaux cas de test basés sur des modèles existants, la traduction de la documentation en code maintenable et un travail de structure récurrent. En l'absence de cette base, un travail de reprise était nécessaire, parfois plus important qu'avec une création manuelle. C'est la pure vérité, et c'est pourquoi nous abordons d'abord la structure, puis les outils.
Il est important de noter qu'aucun des cinq points mentionnés ci-dessus ne relève d'un problème d'IA. Des connaissances non documentées, des résultats de tests trompeusement positifs, des retards de maintenance, des schémas d'erreur trompeurs et des règles de confidentialité floues existaient déjà. L'assistant n'a fait que les rendre visibles et urgents.
Ce que cela signifie pour votre projet
Si vous envisagez d'intégrer l'IA à votre automatisation des tests, voici, d'après notre expérience, les questions essentielles à se poser pour commencer :
- À quel moment de votre projet quelque chose pourrait-il mal tourner sans que personne ne s'en aperçoive ?
- Quel savoir réside uniquement chez les individus ?
- Quelle part de votre budget est consacrée à la maintenance plutôt qu'à l'achat de nouvelles couvertures ?
- Comment savoir, à partir d'un avis, si un test vérifie réellement ce que son nom indique ?
- Quelles informations un employé est-il autorisé à saisir dans un outil d'IA, et où cela est-il consigné par écrit ?
Quiconque peut répondre à ces questions a déjà accompli l'essentiel du travail. Trouver l'outil adéquat devient alors l'étape la plus facile.
- Vous souhaitez savoir comment cela peut s'appliquer à votre situation ? Contactez-nous.
Dans un prochain article, nous examinerons ce sujet sous l'angle de la conformité. Quelles preuves un auditeur attend-il lorsque l'IA est utilisée comme outil de test ?.
